|
|
|
|
|
|
IT Policy & Security Compliance
|
IT policy compliance provides proactive policy enforcement and remediation, a consolidated view of compliance to multiple regulations and standards in a single assessment, plus automated archiving and data retention. IT policy compliance can help organizations meet their compliance requirements via three-pronged approaches.
DEFINE IT CONTROL ENVIRONMENT:
The first step is to identify threats to non-compliance and develop the appropriate policies to mitigate the risks.
CONTROL IMPLEMENT AND MANAGE:
Next, your compliance team needs to establish controls that can be easily managed and monitored in order to assess compliance and remediate any problems.
GOVERN AUDIT AND EXAMINE:
Lastly, you need to analyze the effectiveness of controls, optimize them when required, and demonstrate due diligence to both internal and external constituencies.
BIGGEST IT SECURITY THREATS:
What is the biggest IT security threat? IT itself, according to recent reports from IDC and Carnegie Mellon/DoD. To begin with, IDC research finds that enterprise companies rank insider sources as their top security threat (Source: "Privileged Password Management, "Sally Hudson", and IDC). In addition, research from Carnegie Mellon University for the Department of Defense (DoD) finds that when it comes to insider attacks, 86% of perpetrators held technical positions. Of these, 57% performed the attack after termination. (Source: Management and Education of the Risk of Insider Threat (MERIT), CERT3 Program, Software Engineering Institute and CyLab at Carnegie Mellon University).
Both reports found that insider attacks result in lost business, legal liability and, inevitably, failed audits. In one case study, it took 115 employees 1800 hours to restore data deleted by a disgruntled insider. At the time of the attack, the perpetrator was an ex-employee of the IT department who was able to remotely access key systems. According to these reports, IT insiders commonly acquire and maintain powerful system access even after termination by using privileged accounts and passwords.
1. Create an inventory of privileged passwords:
Privileged passwords are the non-personal, shared passwords that exist in virtually every device or software application in an enterprise, such as root on a UNIX server, Administrator on a Windows workstation, and an Application ID used by a script to connect two databases. Many companies begin the process of securing their privileged passwords by taking an inventory of how many exist and how often they’re updated.
In this effort, it is important to note that privileged passwords exist in many places within your enterprise, such as:
• Administrative accounts that are shared by multiple IT professionals and come predefined by the manufacturer. These include UNIX root, Cisco enable, DBA accounts, Windows domain and so on.
• General shared administrative accounts such as help-desk, fire-call, operations and emergency accounts.
• Hard-coded and embedded application accounts including resource DB IDs, Generic IDs, batch jobs, testing scripts and application IDs.
• Service accounts such as Windows service accounts and scheduled tasks.
• Personal computer accounts including the Windows Local Administrator on laptops and desktops.
Now many organizations still manually update these passwords, if they change them at all. For example, a recent study showed that 42% of application passwords are never changed (Source: Cyber-Ark Enterprise Privileged Password Survey).
2. Define the role of Identity & Access Management (IAM):
When it comes to managing privileged passwords, a common first mis-step is to import all Administrator or Shared IDs into a system built for managing human identities. The benefit of this approach is that you can quickly start to automatically update your organization’s privileged passwords. The negative? Your organization still has no way of assigning individual responsibility. For example, the reports will show that the “Administrator” identity downloaded your database of top clients. You won’t be able to tie that action – or its consequences to a particular individual.
To deliver true accountability, your system for Privileged Password Management (PPM) must tie individual identities to shared accounts. This is incredibly sensitive data – a hacker’s dream list of all your privileged passwords – so this information must be stored in an exceptionally secure place. IAM solutions are not designed to store sensitive data and typically partner with a PPM solution for the privileged accounts/passwords.
3. Apply change policies to privileged passwords:
This may sound obvious, but you’d be surprised how often policies for privileged passwords are not as explicit as those for their human counterparts. For instance, you may now change the password on your laptop every 30 days, however surveys show that workstation has a 20% chance of NEVER having had the Administrator ID changed from its default (Source: Cyber-Ark Enterprise Privileged Password Survey.) In other words, if you lost your laptop, the finder may not know who you are or what company you work for… but they can search the web to find the default Administrator password that ships with a Dell Latitude D600. Within seconds, your laptop’s new owner will have more access to your systems than you do.
4. Create a staged approach to deployment:
Privileged passwords are literally the keys to your kingdom and must be controlled properly. One common stumbling block for projects around privileged passwords is that once the password inventory is created, the sheer volume and prevalence of these codes is overwhelming. Personnel can say:”we never secured these before so why bother now? “In these situations, the most successful auditors take a deep breath, drink a tall latte and start putting together a stepped plan with reasonable deadlines, deliverables and consequences.
5. Remember computers are people too:
While 99% of enterprises change passwords for employees, up to 42% never change hard-coded and embedded passwords for application IDs, testing scripts and batch jobs. (Source: Cyber-Ark Enterprise Privileged Password Survey.) According to Mark Diodati of the Burton Group, this creates an App2App password problem that is”exponential. For example: 300 hosts x 2 applications per host x 5 scripts per application = 3000 stored passwords. “Often, these passwords are in clear text and readily available to every developer or database administrator in an organization.
All in all, no privileged password management system is complete without an App2App component. However, since application passwords are stored in scripts that must be re-coded, tested and deployed, most organizations break out fixing past code from making future mistakes. Once again, a stepped plan can be your best friend.
SECURITY INFORMATION AND EVENT MANAGEMNET:
Fail to prepare, as the saying goes, and you prepare to fail. This maxim certainly applies to most large-scale IT projects, and doubly so for Security Information and Event Management (SIEM) projects.
Recent figures from industry observers including Gartner have shown that SIEM projects have a surprisingly higher failure rate compared to other projects. Does that mean the SIEM concept is flawed? Not at all – otherwise companies wouldn’t even be attempting SIEM deployments. The benefits of SIEM are clear: rapid ROI, ongoing savings in manpower and equipment, more effective security management, and compliance with key legislation.
No, the failures simply highlight the fact SIEM is one of the most ambitious and far-reaching projects that can be undertaken by a company. Because SIEM ties together so many disparate technologies, and working groups – from specialized IT teams to C-level board executives, including risk control groups, compliance executives and HR on the way, project success is inevitably based on careful preparation and planning.
POINT OF FAILURE:
So, what are the reasons behind the project failures? Gartner, McKinsey and other sources state that the leading reasons were, not altogether surprisingly:
• No cross-function steering committee was appointed at the outset.
• Project owners did not have clearly defined roles.
• Projects had no defined timescale, or where too ambitious for the timescale.
• Requirements were poorly defined.
• Poor planning for continuity or remediation.
Inevitably, poor involvement of non-IT teams was close behind. These reasons clearly highlight planning as an essential before starting a SIEM project. But where should the planning and preparatory effort be directed, to minimize both risks and costs in a SIEM deployment?
Reference
The British Computer Society
Symantec Enterprise
BIOS
Posted by ROOT Technologies
|
|
|
